Systems and methods for resolving over multiple hierarchies

ABSTRACT

The present disclosure relates to resolving over multiple hierarchies. Specifically, various techniques and systems are provided for adjusting multiple hierarchies for consistency within levels of the hierarchies, using an optimization-based approach that results in an accurate projection across dimensions and levels in hierarchies. The systems and methods may include receiving data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values, identifying a common level node and a target level node for each of the hierarchies, identifying a linking constraint, wherein the linking constraint includes a rule to a node from a hierarchy to make it consistent with a node from another hierarchy, applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values, applying the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values, and generating a resolved hierarchy using the updated target node values.

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a non-provisional of and claims the benefit and priority under 35 U.S.C. §119(e) of U.S. Provisional App. No. 62/011,379. That U.S. Provisional application was filed on Jun. 12, 2014, and is incorporated by reference herein for all purposes.

FIELD

The present disclosure relates to resolving over multiple hierarchies. Specifically, various techniques and systems are provided for adjusting multiple hierarchies for consistency within levels of the hierarchies, using an optimization-based approach that results in an accurate projection across dimensions and levels in hierarchies.

BRIEF SUMMARY

The present disclosure relates to resolving over multiple hierarchies. Specifically, various techniques and systems are provided for adjusting multiple hierarchies for consistency within levels of the hierarchies, using an optimization-based approach that results in an projection across dimensions and levels in hierarchies. In an embodiment, a computer-program product may be tangibly embodied in a non-transitory machine-readable storage medium. The non-transitory machine-readable storage medium may include instructions configured to cause a data processing apparatus to receive data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values, identify a common level node and a target level node for each of the hierarchies, identify a linking constraint, wherein the linking constraint includes a rule to adjust a node from a hierarchy to make it consistent with a node from another hierarchy, apply the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values, apply the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values, and generate a resolved hierarchy using the updated target node values.

In an aspect, the updated common node values have the same value as a value of one of the common level nodes before the linking constraint is applied to the common level node of each of the hierarchies. In another aspect, the computer-program product may further comprise instructions configured to cause the data processing apparatus to compute a change in target node value associated with each of the two or more hierarchies, determine that the change in target node value associated with one or more of the hierarchies are above a predetermined threshold, and re-apply the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating alternative common node values associated with the common level nodes, wherein the alternative common node values are the same node values, and wherein the alternative common node values are different than the updated target node values. In another aspect, a target level node of a hierarchy includes a most accurate data of all nodes within the hierarchy. In another aspect, applying a linking constraint to common level nodes forces common level node values associated with the common level nodes to be the same value. In another aspect, the computer-program product may further comprise instructions configured to cause the data processing apparatus to compute disaggregation factors for each of the nodes of two or more hierarchies, and determine, using the disaggregation factors for a parent node in a hierarchy, whether a set of child nodes of the parent node comply with flow conservation properties, wherein determining whether a set of child nodes of the parent node comply with flow conservation properties includes determining if a sum of the node values of the child nodes equals the node value of the parent node. In another aspect, determining that the sum of the node values of the child nodes does not equal the node value of the parent node includes comparing the difference between the sum of the node values of the child nodes and the node value of the parent node to a predetermined threshold. In another aspect, the computer-program product may further comprise instructions configured to cause the data processing apparatus to determine that the set of child nodes of the parent node comply with flow conservation properties if the difference between the sum of the node values of the child nodes and the node value of the parent node are less than the predetermined threshold.

In another embodiment, a computing device may comprise one or more processors, and a memory having instructions stored thereon, which when executed by the one or more processors. The processor may cause the computing device to perform operations including receiving data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values, identifying a common level node and a target level node for each of the hierarchies, identifying a linking constraint, wherein the linking constraint includes a rule to adjust a node from a hierarchy to make it consistent with a node from another hierarchy, applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values, applying the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values, and generating a resolved hierarchy using the updated target node values.

In an aspect, the updated common node values have the same value as a value of one of the common level nodes before the linking constraint is applied to the common level node of each of the hierarchies. In another aspect, the computing device may further comprise instructions, which when executed by the one or more processors, cause the computing device to perform operations including computing a change in target node value associated with each of the two or more hierarchies, determine that the change in target node value associated with one or more of the hierarchies are above a predetermined threshold, and re-apply the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating alternative common node values associated with the common level nodes, wherein the alternative common node values are the same node values, and wherein the alternative common node values are different than the updated target node values. In another aspect, a target level node of a hierarchy includes a most accurate data of all nodes within the hierarchy. In another aspect, applying a linking constraint to common level nodes forces common level node values associated with the common level nodes to be the same value. In another aspect, the computing device may further comprise instructions, which when executed by the one or more processors, cause the computing device to perform operations including computing disaggregation factors for each of the nodes of two or more hierarchies, and determine, using the disaggregation factors for a parent node in a hierarchy, whether a set of child nodes of the parent node comply with flow conservation properties, wherein determining whether a set of child nodes of the parent node comply with flow conservation properties includes determining if a sum of the node values of the child nodes equals the node value of the parent node. In another aspect, determining that the sum of the node values of the child nodes does not equal the node value of the parent node includes comparing the difference between the sum of the node values of the child nodes and the node value of the parent node to a predetermined threshold. In another aspect, the computing device may further comprise instructions, which when executed by the one or more processors, cause the computing device to perform operations including determining that the set of child nodes of the parent node comply with flow conservation properties if the difference between the sum of the node values of the child nodes and the node value of the parent node are less than the predetermined threshold.

In another embodiment, a computer-implemented method may comprise receiving data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values, identifying a common level node and a target level node for each of the hierarchies, identifying a linking constraint, wherein the linking constraint includes a rule to adjust a node from a hierarchy to make it consistent with a node from another hierarchy, applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values, applying the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values, and generating a resolved hierarchy using the updated target node values.

In an aspect, the updated common node values have the same value as a value of one of the common level nodes before the linking constraint is applied to the common level node of each of the hierarchies. In another aspect, the method may further comprise computing a change in target node value associated with each of the two or more hierarchies, determine that the change in target node value associated with one or more of the hierarchies are above a predetermined threshold, and re-apply the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating alternative common node values associated with the common level nodes, wherein the alternative common node values are the same node values, and wherein the alternative common node values are different than the updated target node values. In another aspect, a target level node of a hierarchy includes a most accurate data of all nodes within the hierarchy. In another aspect, applying a linking constraint to common level nodes forces common level node values associated with the common level nodes to be the same value. In another aspect, the method may further comprise computing disaggregation factors for each of the nodes of two or more hierarchies, and determine, using the disaggregation factors for a parent node in a hierarchy, whether a set of child nodes of the parent node comply with flow conservation properties, wherein determining whether a set of child nodes of the parent node comply with flow conservation properties includes determining if a sum of the node values of the child nodes equals the node value of the parent node. In another aspect, determining that the sum of the node values of the child nodes does not equal the node value of the parent node includes comparing the difference between the sum of the node values of the child nodes and the node value of the parent node to a predetermined threshold. In another aspect, the method may further comprise determining that the set of child nodes of the parent node comply with flow conservation properties if the difference between the sum of the node values of the child nodes and the node value of the parent node are less than the predetermined threshold.

This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any or all drawings, and each claim.

The foregoing, together with other features and embodiments, will become more apparent upon referring to the following specification, claims, and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram including a system for an organization, according to embodiments of the present technology.

FIG. 2 illustrates an example section of a hierarchy, according to embodiments of the present technology.

FIG. 3 includes an example of two hierarchies, according to embodiments of the present technology.

FIG. 4 includes a combination of hierarchies, according to embodiments of the present technology.

FIG. 5 includes two hierarchies, according to embodiments of the present technology.

FIG. 6 illustrates an example set of hierarchies that can be used to determine how the impact on the target level node values may be minimized, according to embodiments of the present technology.

FIG. 7 illustrates an example set of hierarchies that can be used to determine how the impact on the target level node values may be minimized, according to embodiments of the present technology.

FIG. 8 illustrates an example set of hierarchies that can be used to determine how the impact on the target level node values may be minimized, according to embodiments of the present technology.

FIG. 9 illustrates an example resolved hierarchy, according to embodiments of the present technology.

FIG. 10 illustrates a block diagram showing the logical structure of a hierarchy, according to embodiments of the present technology.

FIG. 11 is a flow chart showing an example process for resolving multiple hierarchies, according to embodiments of the present technology.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments of the technology. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and description are not intended to be restrictive.

The ensuing description provides example embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the example embodiments will provide those skilled in the art with an enabling description for implementing an example embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the technology as set forth in the appended claims.

Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

The term “machine-readable storage medium” or “computer-readable storage medium” includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction(s) and/or data. A machine-readable medium may include a non-transitory medium in which data can be stored and that does not include carrier waves and/or transitory electronic signals propagating wirelessly or over wired connections. Examples of a non-transitory medium may include, but are not limited to, a magnetic disk or tape, optical storage media such as compact disk (CD) or digital versatile disk (DVD), flash memory, memory or memory devices. A computer-program product may include code and/or machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a machine-readable medium. A processor(s) may perform the necessary tasks.

Systems depicted in some of the figures may be provided in various configurations. In some embodiments, the systems may be configured as a distributed system where one or more components of the system are distributed across one or more networks in a cloud computing system.

The present disclosure relates to resolving over multiple hierarchies. Specifically, various techniques and systems are provided for adjusting multiple hierarchies for consistency within levels of the hierarchies using an optimization-based approach that results in a more accurate projection across dimensions and levels in hierarchies. Hierarchies can be represented as rooted trees and include levels representing different aggregations of the time series, for example, statistical characteristics, seasonal clusters, or a business dimension for which the demand and supply planning is taking place. Each level may contain one or more nodes, which represent a time series. For example, one hierarchy may be focused on one or more products (e.g., as created by a product manager in a product division of the organization) and another hierarchy may be focused on distribution of the one or more products (e.g., as created by a distribution manager in a distribution division of the organization). A hierarchy may include only a few nodes, may exceed millions, or somewhere in between.

Furthermore, different hierarchies within an organization may represent, and be created by, different parts of the organization. In other words, different parts of an organization may map their planning needs in different hierarchies or planning structure, and therefore using different criteria and focuses. For example, one hierarchy may be focused on one or more products (e.g. as created by a product manager in a product division of the organization) and another hierarchy may be focused on distribution of the one or more products (e.g. as created by a distribution manager in a distribution division of the organization).

Each hierarchy may include multiple aggregation levels. Each level may include a different portion of a projection segment or planning chain related to the part of the organization that the hierarchy is focused on. For example, a product dimension hierarchy may include levels focused on the brand of the product, the type of the product, the packaging of the product, the distribution of the product, and the SKU of the product, among others. Different parts or sub-parts of the organization may also focus on one or more certain levels within a planning hierarchy. Therefore, since the planning hierarchies may focus on separate, disjointed parts of the organization, an organization may be unable to view a single hierarchy or plan that focuses on all aspects of the organization.

Embodiments of the present technology include systems and methods for resolving multiple hierarchies. The hierarchies (e.g., two or more hierarchies) may be adjusted using common or overlapping levels within each of the hierarchies. For example, even though multiple hierarchies may be focused on different aspects of the time series statistical properties, or an organization, the hierarchies may overlap or share levels. The hierarchies may converge or overlap at a common or a common level (e.g. SKU-store level), or “leaf” level. Embodiments of the present technology may adjust the respective common levels of the multiple hierarchies to make them consistent or equal, which may affect the other levels of the hierarchies (e.g. a target level). The hierarchies may be adjusted or resolved so as to minimize the impact of the reconciliation on certain levels of the hierarchies, which may already be, for example, important, accurate, or effective. Such embodiments of the present technology are described herein with respect to FIGS. 1-11.

FIG. 1 illustrates a block diagram including a planning system for an organization, according to embodiments of the present technology. Planning system 100 includes various blocks representing different aspects of the planning system of an organization. Planning system 100 includes various blocks, each of which represent a different aspect or portion (e.g. a department) of an organization's projection model. For example, planning system 100 includes demand projecting block 125, demand planning block 130, distribution planning block 135, production planning block 140, and materials planning block 145, among others. Although some of the different portions of an organization may overlap, others may be relatively disjointed within the organization. Furthermore, as noted, each portion of the organization may produce or generate a projection plan or hierarchy by itself without consulting with or being consistent with the other portions or departments of the organization. Embodiments of the present technology may allow an organization to resolve or merge such disjointed hierarchies.

Embodiments of the present technology may be described herein with respect to demand projecting 125 and demand planning 130. However, embodiments of the present technology may also be applied to various other aspects of an organization, including other aspects represented, for example, elsewhere in planning system 100.

FIG. 2 illustrates an example section 200 of a hierarchy, according to embodiments of the present technology. Hierarchy 200 includes four different levels: root (or zero) level 202, 1st level 204, 2nd level 206, and 3rd level 208. Even though hierarchy 200 includes four levels, hierarchy 200 may be include fewer (e.g., 1, 2 or 3) levels or more (e.g., 5, 6, 7, etc.) levels according to embodiments of the present technology. Each level of a hierarchy may represent a step or portion of the projection represented by the hierarchy. For example, a product-focused department of a retail organization may generate a projection hierarchy that includes levels (e.g., categories) of the brand of each product, the package type of each product, the SKU of each product, the distributor that will distribute the product, and the store that will carry the product. Each of those levels may be represented in a hierarchy, such as hierarchy 200, as a different level. For example, root level 202 may represent a set of products (e.g., all products of that organization), 1st level 204 may represent product line, 2nd level 206 may represent the SKU of each product, and 3rd level 208 may represent the store that will carry the product.

Each level within hierarchy 200 includes one or more nodes, i.e. time series. For example, root level 202 includes just one node, 1st level 204 includes two nodes, 2nd level 206 includes four nodes, and 3rd level 208 includes sixteen nodes. Each node within a level may represent a specific item within the category that the level represents. For example, if 1st level 204 of hierarchy 200 represents the product line of the product, each node within 1st level 204 may represent a different product line that is possible for the product in question. As used herein, the terms “parent” node and “child” node or “children” nodes are used to describe the relationship between nodes that are connected between different levels, where the “parent” node is the node that is one level higher in the hierarchy than the “child” node or “children nodes. For example, if root level 202 represents different products within the hierarchy, and node NO represents a dish washer product, then the nodes from 1st level 204 (i.e. the “child” or “children” nodes) that connect to node NO (i.e. the “parent” node) may represent the different types of design that exist for the dish washer product. More specifically, nodes N1 and N2 may represent different types of dish washers, such as color, functionality and capacity, respectively. In another example, if 1st level 204 represents different types of packaging within the hierarchy, and node NO represents a product that is packaged in a glass bottle, then the nodes from 2nd level 206 (i.e. the “child” or “children” nodes) that connect to node NO (i.e. the “parent” node) may represent the different sku's that may be bottled using a glass bottle.

Each node within each level may include a value that the node represents at a specific point in time. For example, if a level represents different types of packaging for a company's products, then each node within the level may include a value that is or represents the demand of the different types of packaging, at a specific point in time. More specifically, each level may include either a type of packaging (e.g. glass bottle, plastic bottle, can, etc.) or may include a numerical or other value (e.g. 1, 2, 3, etc.) that represents a type of packaging. Such values may exist within each node of each level no matter what each level represents within the hierarchy and the organization.

Since node NO may represent one type of product within a larger hierarchy produced by, for example, a certain department of an organization, one or more other nodes on root level 202 may exist, and each may represent a different type of product. Furthermore, hierarchy 200 may only be one hierarchy of the two or more hierarchies generated by the organization or by statistical reasoning. For example, each department or combinations of departments (or portions of departments) may generate their own hierarchy (e.g. projection or forecasting hierarchy) that may look similar to hierarchy 200 or a combination of portions of hierarchies that are similar to hierarchy 200. Each of the hierarchies generated within an organization may overlap or share common levels or portions of levels, but may generally be dissimilar in other respects. Therefore, the hierarchies may be resolved or adjusted to facilitate generating a single time series at some common level that includes information from individual hierarchies. As used herein (both with respect to FIG. 2 and later figures), the terms projection or projecting may describe a prediction or predicting, a plan or planning, an estimate or estimating, a prediction or predicting, a prognostication or prognosticating, a forecast or forecasting, among others.

FIG. 3 includes an example of two hierarchies 300, according to embodiments of the present technology. More specifically, the combination of hierarchies 300 includes two hierarchies, Hierarchy A 340 and Hierarchy B 350. Hierarchy A 340 includes four levels, root level 302A, 1^(st) level 304A, 2^(nd) level 306A, and 3^(rd) level 308A. Hierarchy B 350 includes four levels, root level 302B, 1^(st) level 304B, 2^(nd) level 306B, and 3^(rd) level 308B.

As noted, the two hierarchies may represent different portions, departments of an organization or a pure statistical hierarchy, and may reflect the future goals or focuses of their respective departments or statistical buckets. To adjust the two independent hierarchies into a single hierarchy (or to adjust both hierarchies to make them consistent), the hierarchies may include one or more levels and nodes within levels to be made consistent. In other words, the system may recognize that a certain level of each of the hierarchies represent a similar aspect or phase of the organization. Even though the hierarchies may have been generated from, for example, two different departments of the organization and may be generally focused on their respective departments, the hierarchies may overlap at a certain level. For example, if hierarchy A represents a projection for a product-focused department and hierarchy B represents a projection for a location-focused department, both hierarchies may include levels focused on, for example, the type of products being sold by the organization or sku-store.

Once a common level has been identified, the nodes (or, more specifically, the node values behind the nodes) may be used in process to adjust the two hierarchies. To resolve (or, for example, to reconcile) the two hierarchies, a set of linking constraints may be applied to the two hierarchies. A linking constraint is a rule that limits how node values within the hierarchies may be changed. As shown in FIG. 3, to resolve hierarchies A and B with each other to yield a set of consistent, similar or matching hierarchies, the common level 309 operates as the linking level. As used herein (both with respect to FIGS. 2 and 3 and later figures), the terms/phrases resolving or making consistent may describe merging, reconciling, making match within a threshold degree of similarity, among others.

FIG. 4 includes a combination of hierarchies 400, according to embodiments of the present technology. Hierarchy A 440 includes four levels, root level 402A, 1^(st) level 404A, 2^(nd) level 406A, and 3^(rd) level 408A. Hierarchy B 450 includes four levels, root level 402B, 1^(st) level 404B, 2^(nd) level 406B, and 3^(rd) level 408B.

The combination of hierarchies 400 is similar to the combination of hierarchies 300 in FIG. 3 and includes the same example nodes. As shown in FIG. 4, to resolve hierarchies A and B with each other to yield a set of consistent hierarchies, the common level 409 may be identified as the linking level where reconciliation is initiated. In other words, individual common level 408A (3th level of Hierarchy A 440) and 408B (3^(rd) level of hierarchy B 450) may be resolved, reconciled or otherwise made consistent with each other. More specifically, the node values of levels 408A and 408B may be adjusted so that their node values are equal. This rule that the node values for the hierarchy A common level and the hierarchy B common level may be an example of a linking constraint. As shown in FIG. 4, levels 408A and 408B include the same number of nodes and node values. Therefore, the values of the corresponding nodes between the two levels (one from each hierarchy) may be made to be the same value. For example, the node value for node H1-L3 k may be made the same as the node value for node H2-L3 k. This process may be repeated for each of the node values within the levels 409 so that each of the node values for the nodes within the levels are equal. In other words, this process may cause the values within levels 408A and 408B to be the same.

In causing the node values for the nodes in the common levels to be equal, the node values for the common level from one of the hierarchies (i.e. the node values for level 408A or for level 408B) may be changed to include the same values as the node values for the corresponding common level from the other hierarchy. In other words, the node values for level 408A may be changed so that they are equal to the node values for level 408B, or the node values for level 408B may be changed so that they are equal to the node values for level 408A. Alternatively, all of the node values in the common level (i.e. the node values for both level 408A and 408B) may be changed to be equal to a set of values different than the node values of level 408A or 408B.

FIG. 5 includes two hierarchies 500, according to embodiments of the present technology. Hierarchy A 540 includes four levels, root level 502A, 1^(st) level 504A, 2^(nd) level 506A, and 3^(rd) level 508A. Hierarchy B 550 includes four levels, root level 502B, 1^(st) level 504B, 2^(nd) level 506B, and 3^(rd) level 508B.

The two hierarchies 500 include a common level of nodes, L31 through L3 n. More specifically, nodes L31 through L31 include the combined level node values of levels 409 after the respective node values within the two hierarchies being resolved (i.e. reconciled) were brought into alignment with each other, as described above with respect to FIG. 4.

Any time the node values for nodes within a level of a hierarchy are changed, the node values for nodes within other levels of the hierarchy may also be adjusted automatically. For example, if a common level of a hierarchy is a sku-store level of a retail business hierarchy, and numbers of each sku at the various stores of the retail company are adjusted, then the numbers for each of the different types of packaging that apply to the different sku's may also change. In other words, when a child node changes value, the values of one or more of the parent nodes of the child node may also change. Any or all of the levels within each of the hierarchies being resolved may be affected by the equalization of the common levels.

One or more of the levels within each of the hierarchies being made consistent and aligned may be recognized by the system as important, realistic, or accurate. For example, the node values within a certain level of a hierarchy may be identified by the system as having a high level of accuracy in projecting or forecasting future needs for the organization. In other words, while a set of lower level child nodes of a hierarchy may be relatively inaccurate due to the volatile and common nature of that level, higher level parent nodes may be more accurate. More specifically, for example, while the sku-store level of a hierarchy for a retail-based business may be relatively inaccurate due to the volatile and common nature of that level, one or more other levels within the hierarchy, such as the product type or packaging type levels, may be more accurate. Such an accurate or realistic level may be identified as a “target” level. An example set of target levels within hierarchies 400 may be target levels 404A. Since a target level may be considered to be the most accurate portion of a hierarchy, the system may choose to avoid changing the node values of the target level as much as possible. In other words, even though node values within other levels within the hierarchies being made consistent, reconciled or aligned may be changed during reconciliation and alignment, the system may choose to perform the process so as to affect the target level node values as little as possible, or to minimize the impact on the target level.

As noted, when the common level from the two or more hierarchies are brought into alignment by relating and transforming their node values, the resulting node values of the common level may be changed to include a variety of different values. More specifically, the node values for the resulting common level may be the same as the node values for one of the two pre-aligned common levels, or the node values for the resulting level may include a set of new node values, or a combination of both. Also as noted, when the common level of the hierarchies are aligned, other levels of the hierarchies (including a target level) may also be impacted. When a target level is identified, and the common level is adjusted for consistency, the aligned node values for the common level may be chosen so that impact on the target level node values is minimized. In other words, the node values that the common level of hierarchies A and B may be changed to be a set of values that, when compared to any other set of numbers, minimizes the amount that the target level node values are changed.

In an embodiment, the multiple hierarchies may be adjusted or resolved for consistency by minimizing the squared distance between current target values and updated values, and minimizing the squared distance between current disaggregation factors and updated disaggregation factors, and finally adding a set of linking constraints. This can be expressed in the following optimization model:

$\min\limits_{\alpha,\theta}{\sum\limits_{i = 1}^{M}\left( {{\sum\limits_{j = 1}^{M_{i}}{w_{ij} \times \left( {{\hat{X}}_{ij} - {\sum\limits_{k = 1}^{N}{\sum\limits_{l = 1}^{M}{\alpha_{lk} \times {\hat{y}}_{lk}}}}} \right)^{2}}} + {\sum\limits_{k = 1}^{N}\left( {{\hat{\gamma}}_{ik} - \theta_{ik}} \right)^{2}}} \right)}$

where M is the number of hierarchies, M_(i) is the number of target nodes in hierarchy i, w_(ij) is the weight given to target node j in hierarchy i, {circumflex over (X)}_(ij) is the projected or forecasted value in target node j in hierarchy i, N is the number of common level nodes (which, for example, is the same for all hierarchies), α_(lk) is the weight given to common level node k in hierarchy l, ŷ_(kl) is the value in common node k in hierarchy l, and {circumflex over (γ)}_(ik) is the disaggregation factor in common node k in hierarchy i. The first term of this equation minimizes the squared distance between initial target level node value and its updated value, and the second term of the equation minimizes the squared distance between the initial disaggregation factor and its updated value.

For a some hierarchies, it may be necessary to aggregate a set of child nodes to get to a common node level. In such a case, ŷ_(lk) may be replaced by a sum of the child nodes, ŷ_(lk) being the parent node.

α_(lk) ≥ 0, θ_(lk) ≥ 0, ∀k, l ${{\sum\limits_{l = 1}^{M}\alpha_{lk}} = b},{\forall k},{b > 0}$ ${{\sum\limits_{l = 1}^{M}{\alpha_{lk} \times {\hat{y}}_{lk}}} - {\theta_{lk} \times {\sum\limits_{i = 1}^{N}{\sum\limits_{j = 1}^{M}{\alpha_{ji} \times {\hat{y}}_{ji}}}}}} = 0$ ∀k, l

FIG. 6 illustrates an example set of hierarchies 600 that can be used to determine how the impact on the target level node values may be minimized, according to embodiments of the present technology. Hierarchies 600 include hierarchy 640 and hierarchy 650. As noted, one or more of the levels within each of the hierarchies being aligned may be recognized by the system as important, realistic, or accurate, and that level may be called the target level. For example, the second level (nodes A and B in hierarchy 640 and nodes AA, BB, and CC in hierarchy 650) may be the target level. Furthermore, each of the hierarchies may overlap or share common levels or portions of levels, called the common level. The common levels may be reconciled to facilitate generating a single time series at some common level that includes information from individual hierarchies. In hierarchies 600, the third level (nodes L11-L18 in hierarchy 640 and nodes L21-L28 in hierarchy 650) may be the common levels.

For an example as shown in FIG. 6, the following equation may determine how the impact on the target level node values may be minimized (we have M=2, M₁=2, M₂=3, N=8, and we set the weights w=1).

${\min\limits_{\alpha,\theta}\left( {A - {\sum\limits_{i = 1}^{4}\left( {{\alpha_{1i} \times L_{1i}} + {\alpha_{2i} \times L_{2i}}} \right)}} \right)^{2}} + \left( {B - {\sum\limits_{i = 5}^{8}\left( {{\alpha_{1i} \times L_{1i}} + {\alpha_{2i} \times L_{2i}}} \right)}} \right)^{2} + \left( {{AA} - {\sum\limits_{i = 1}^{2}\left( {{\alpha_{1i} \times L_{1i}} + {\alpha_{2i} \times L_{2i}}} \right)}} \right)^{2} + \left( {{BB} - {\sum\limits_{i = 3}^{5}\left( {{\alpha_{1i} \times L_{1i}} + {\alpha_{2i} \times L_{2i}}} \right)}} \right)^{2} + \left( {{CC} - {\sum\limits_{i = 6}^{8}\left( {{\alpha_{1i} \times L_{1i}} + {\alpha_{2i} \times L_{2i}}} \right)}} \right)^{2} + {\sum\limits_{k = 1}^{8}\left( {{\hat{\gamma}}_{1k} - \theta_{1k}} \right)^{2}} + {\sum\limits_{k = 1}^{8}\left( {{\hat{\gamma}}_{2k} - \theta_{2k}} \right)^{2}}$ ${{{\text{subject to:}\mspace{20mu} \alpha_{11}} + \alpha_{21}} = 1},{{\alpha_{12} + \alpha_{22}} = 1},{{\alpha_{13} + \alpha_{23}} = 1},{{\alpha_{14} + \alpha_{24}} = 1},{{\alpha_{15} + \alpha_{25}} = 1},{{\alpha_{15} + \alpha_{25}} = 1},{{\alpha_{16} + \alpha_{26}} = 1},{{\alpha_{17} + \alpha_{27}} = 1},{{\alpha_{18} + \alpha_{28}} = 1},{{{\sum\limits_{l = 1}^{2}{\alpha_{l\; 1} \times L_{l\; 1}}} - {\theta_{11} \times {\sum\limits_{i = 1}^{4}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},{{{\ldots \mspace{14mu} {\sum\limits_{l = 1}^{2}{\alpha_{l\; 4} \times L_{l\; 4}}}} - {\theta_{14} \times {\sum\limits_{i = 1}^{4}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},\mspace{20mu} {{{\sum\limits_{l = 1}^{2}{\alpha_{l\; 5} \times L_{l\; 5}}} - {\theta_{15} \times {\sum\limits_{i = 5}^{8}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},\; {{{\ldots \mspace{31mu} {\sum\limits_{l = 1}^{2}{\alpha_{l\; 8} \times L_{l\; 8}}}} - {\theta_{18} \times {\sum\limits_{i = 5}^{8}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},\mspace{14mu} {{{\sum\limits_{l = 1}^{2}{\alpha_{l\; 1} \times L_{l\; 1}}} - {\theta_{21} \times {\sum\limits_{i = 1}^{2}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},\mspace{14mu} {{{\sum\limits_{l = 1}^{2}{\alpha_{l\; 2} \times L_{l\; 2}}} - {\theta_{22} \times {\sum\limits_{i = 1}^{2}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0}$ $\mspace{14mu} {{{{\sum\limits_{l = 1}^{2}{\alpha_{l\; 3} \times L_{l\; 3}}} - {\theta_{23} \times {\sum\limits_{i = 3}^{5}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},{{{\ldots \mspace{14mu} {\sum\limits_{l = 1}^{2}{\alpha_{l\; 5} \times L_{l\; 5}}}} - {\theta_{25} \times {\sum\limits_{i = 3}^{5}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0}}$ $\mspace{14mu} {{{{\sum\limits_{l = 1}^{2}{\alpha_{l\; 6} \times L_{l\; 6}}} - {\theta_{26} \times {\sum\limits_{i = 6}^{8}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0},{{{\ldots \mspace{14mu} {\sum\limits_{l = 1}^{2}{\alpha_{l\; 8} \times L_{l\; 8}}}} - {\theta_{28} \times {\sum\limits_{i = 6}^{8}{\sum\limits_{j = 1}^{2}{\alpha_{ji} \times L_{ji}}}}}} = 0}}$

FIGS. 7-9 illustrate a numerical example to determine how the impact on the target level node values may be minimized, according to embodiments of the present technology. Similar to as described with respect to FIG. 6, the second level may be assigned as the target level as shown in FIG. 7, and the third level may be assigned as the common level, as shown in FIG. 8. The target level may be chosen, for example, because that level is identified as having a high level of accuracy as compared to other levels within the hierarchies. As shown in FIG. 7, the third level nodes within the two hierarchies to be reconciled have corresponding nodes in the same level of the other hierarchy with the same value. This makes sense since those nodes are at the common level.

As shown in FIG. 8, the lower (third) common level may be aligned, or in other words the values of the nodes changed to be aligned. This procedure will also define a set of disaggregation factors, for later use in the multiple reconciliation model.

Then, the multiple hierarchies may be adjusted over the common level by minimizing the squared distance between current target values and updated values, and minimizing the squared distance between current disaggregation factors and updated disaggregation factors, and finally add a set of linking constraints. The common levels are equal, as shown in FIG. 9.

In another example embodiment of the present technology, consider the situation where one hierarchy generates an hourly projection and another hierarchy generates weekly projection. In that situation, the hierarchies are different, and they are also generating projections at two different frequencies. This difference in frequency may be handled by adding a weekly level common level and, a weekly target level in the hourly projection hierarchy. In other words, we aggregate the hourly projections to a week level. The disaggregation factors going from week to hours are then included in the optimization model through constrains. In a different scenario with different frequencies does not change the problem, and can be solved in the same way.

FIG. 10 illustrates a block diagram 1000 showing the logical structure of a planning hierarchy, according to embodiments of the present technology. Block diagram 1000 includes a block 1012 that represents the objective function being applied to the planning hierarchies. For example, the objective function may include applying Equation 1 to the node values within the levels of the hierarchies, which may be represented by block 1020 (the node values, or variables, at specified levels within the hierarchies). Block diagram 1000 also includes block 1018, which represents the linking constraint or constraints being applied to the hierarchies. As noted, a linking constraint may be applied to a level of the hierarchies, such as the operational levels of the hierarchies. An example linking constraint, or rule, may include making the node values from within an operational level of two or more hierarchies equal, as described herein with respect to FIGS. 8-9.

However, other constraints may be applied in the process of resolving multiple hierarchies according to embodiments of the present technology. More specifically, constraints may be applied to the hierarchies to maintain logical consistency of the planning hierarchies at all times. Block diagram 1000 includes a block 1014, which represents one or a group of flow conservation constraints. Flow conservation constraints may enforce conservation of flow within a hierarchy. For example, flow conservation constraints may enforce the rule that the node value of a parent node should equal the sum of the values of the children nodes that flow to that parent node. Applying such a rule throughout a hierarchy may help to maintain logical consistency throughout the hierarchy.

Although flow conservation constraints may enforce the rule that the node value of a parent node should equal the sum of the values of the children nodes that flow to that parent node, the constraints may enforce this rule too strictly or literally. For example, the summing of node values may cause round off error to lead to a sum that is slightly different than the node value of the parent node. Such a difference or error may cause the system to assume an inconsistency or infeasibility within the hierarchy. However, such a difference may be compared to a predetermined or dynamic threshold to determine if the difference is large enough to cause an infeasibility. For example, if the error is small enough, a relieving and augmenting variable may cause the error to be ignored by the system, and thus causing the potential infeasibility to be ignored.

Block diagram 1000 also includes a block 1016 that represents a disaggregation factor constraint that may be applied to the hierarchies. A disaggregation factor constraint may be applied to further maintain logical consistency within a hierarchy. A disaggregation factor may enforce a rule that a child node value may be a certain factor (i.e. proportion) of its parent node, and that node value may maintain that factor over time. More specifically, a disaggregation factor constraint represents the rule that the value of a parent node equals a disaggregation factor times the value of a predecessor (or child) node.

Together, the flow conservation constraint or constraints and the disaggregation factor constraint or constraints may help maintain the logical consistency of one or more hierarchies that are according to embodiments of the present technology. Therefore, the flow conservation and disaggregation factor constraints may be applied to one or more hierarchies before and during a reconciliation process, as described herein.

The flow conservation constraint and disaggregation factor constraint may be implemented into different parts of the method described herein, according to embodiments of the present technology. An example method of according to an embodiment of the present technology may include: initializing the node values for all nodes above the operational level; load statistical projection values into the operational (i.e. leaf) level nodes; aggregate the node values from the operational level up to the other levels in the architecture (e.g. root); compute disaggregation factors for each node (e.g. percent splits); fix or adjust the projection values at a desired level in each hierarchy; solve the optimization problem with linear objective; determine and apply linking constraints to the projection values; solve the optimization problem with a quadratic objective; and analyzing artificial flows.

FIG. 11 is a flow chart 1100 showing an example process for resolving multiple hierarchies, according to embodiments of the present technology.

Flow chart 1100 includes step 1102, which includes receiving data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values. The data associated with nodes of the two or more hierarchies may be generated (or loaded from memory/storage) by the system implementing the method instead of being received from a different entity. The data may include information about nodes within the hierarchies, including information about levels within the hierarchy and node values for nodes within each level of the hierarchy.

Flow chart 1100 also includes step 1104, which includes identifying a common level node and a target level node for each of the hierarchies. As noted, a common level may be the lowest level of the hierarchy (e.g. that is associated with the lowest level actions of the organization, such as selling a product in a retail store of a retail organization). A target level may be considered to be the most accurate portion of a hierarchy, and during reconciliation the system may choose to avoid changing the node values of the target level as much as possible. In other words, even though node values within other levels within the hierarchies may be changed during reconciliation, the system may choose to perform the reconciliation so as to affect the target level node values as little as possible, or to minimize the impact on the target level during reconciliation.

Flow chart 1100 also includes step 1106, which includes identifying a linking constraint, wherein the linking constraint includes a rule to adjust a node from a planning hierarchy to make it consistent with a node from another planning hierarchy. A linking constraint, or rule, may include equalizing a common level of each of multiple hierarchies being reconciled. Step 1108 then includes applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values. When applying a linking constraint, such as one to equalize the common levels of the multiple hierarchies, the node values of the nodes within the operational levels of the hierarchies may be adjusted (either one or both of the operational levels). Such changes in the operational level node values may also affect node values for other levels within the hierarchies.

Flow chart 1100 also includes step 1110, which includes applying the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values. After the common node level values are brought into alignment across multiple hierarchies, and the common node values of one or more of the hierarchies are therefore changed, node values within other levels of the one or more hierarchies may also be changed. In other words, a change in one level of a hierarchy may cause changes to be brought throughout one or more other levels of the hierarchies.

Flow chart 1100 also includes step 1112, which includes generating a resolved planning hierarchy using the updated target node values. Once the linking constraint or constraints are applied to the multiple hierarchies, and the hierarchies have been reconciled, the system may generate a hierarchy (e.g. demand plan) that represents both hierarchies. After such a planning hierarchy is generated, it may be written or stored to memory or storage.

In some examples described herein, the systems and methods may include data transmissions conveyed via networks (e.g., local area network, wide area network, Internet, or combinations thereof, etc.), fiber optic medium, carrier waves, wireless networks, etc. for communication with one or more data processing devices. The data transmissions can carry any or all of the data disclosed herein that is provided to or from a device.

Additionally, the methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem. The software program instructions may include source code, object code, machine code, or any other stored data that is operable to cause a processing system to perform the methods and operations described herein. Other implementations may also be used, however, such as firmware or even appropriately designed hardware configured to carry out the methods and systems described herein.

The systems' and methods' data (e.g., associations, mappings, data input, data output, intermediate data results, final data results, etc.) may be stored and implemented in one or more different types of computer-implemented data stores, such as different types of storage devices and programming constructs (e.g., RAM, ROM, Flash memory, removable memory, flat files, temporary memory, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.). It is noted that data structures may describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.

A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logic flows and figures described and shown in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output.

Generally, a computer can also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a tablet, a mobile viewing device, a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Computer readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media and memory devices, including by way of semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

The computer components, software modules, functions, data stores and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The software components or functionality may be located on a single computer or distributed across multiple computers depending upon the situation at hand.

The computer may include a programmable machine that performs high-speed processing of numbers, as well as of text, graphics, symbols, and sound. The computer can process, generate, or transform data. The computer includes a central processing unit that interprets and executes instructions; input devices, such as a keyboard, keypad, or a mouse, through which data and commands enter the computer; memory that enables the computer to store programs and data; and output devices, such as printers and display screens, that show the results after the computer has processed, generated, or transformed data.

Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated, processed communication, or a combination of one or more of them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a graphical system, a database management system, an operating system, or a combination of one or more of them.

The methods, systems, devices, implementations, and embodiments discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, or various stages may be added, omitted, or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.

Some systems may use Hadoop®, an open-source framework for storing and analyzing big data in a distributed computing environment. Some systems may use cloud computing, which can enable ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Some grid systems may be implemented as a multi-node Hadoop® cluster, as understood by a person of skill in the art. Apache™ Hadoop® is an open-source software framework for distributed computing. Some systems may use the SAS® LASR™ Analytic Server in order to deliver statistical modeling and machine learning capabilities in a highly interactive programming environment, which may enable multiple users to concurrently manage data, transform variables, perform exploratory analysis, build and compare models and score. Some systems may use SAS In-Memory Statistics for Hadoop® to read big data once and analyze it several times by persisting it in-memory for the entire session.

Specific details are given in the description to provide a thorough understanding of examples of configurations (including implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides examples of configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.

Also, configurations may be described as a process that is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure. Furthermore, examples of the methods may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a non-transitory computer-readable medium such as a storage medium. Processors may perform the described tasks.

Having described several examples of configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of the current disclosure. Also, a number of operations may be undertaken before, during, or after the above elements are considered. Accordingly, the above description does not bound the scope of the claims.

The use of “capable of”, “adapted to”, or “configured to” herein is meant as open and inclusive language that does not foreclose devices adapted to or configured to perform additional tasks or operations. Additionally, the use of “based on” is meant to be open and inclusive, in that a process, step, calculation, or other action “based on” one or more recited conditions or values may, in practice, be based on additional conditions or values beyond those recited. Headings, lists, and numbering included herein are for ease of explanation only and are not meant to be limiting.

It should be understood that as used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. Finally, as used in the description herein and throughout the claims that follow, the meanings of “and” and “or” include both the conjunctive and disjunctive and may be used interchangeably unless the context expressly dictates otherwise; the phrase “exclusive or” may be used to indicate situation where only the disjunctive meaning may apply.

Some systems may use cloud computing, which can enable ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Some systems may use the SAS® LASR™ Analytic Server in order to deliver statistical modeling and machine learning capabilities in a highly interactive programming environment, which may enable multiple users to concurrently manage data, transform variables, perform exploratory analysis, build and compare models and score. Some systems may use SAS In-Memory Statistics for Hadoop® to read big data once and analyze it several times by persisting it in-memory for the entire session. Some systems may be of other types, designs and configurations.

While the present subject matter has been described in detail with respect to specific embodiments thereof, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing may readily produce alterations to, variations of, and equivalents to such embodiments. Accordingly, it should be understood that the present disclosure has been presented for purposes of example rather than limitation, and does not preclude inclusion of such modifications, variations or additions to the present subject matter as may be readily apparent to one of ordinary skill in the art.

While this disclosure may contain many specifics, these should not be construed as limitations on the scope or of what may be claimed, but rather as descriptions of features specific to particular implementations. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software or hardware product or packaged into multiple software or hardware products. 

What is claimed is:
 1. A computer-program product tangibly embodied in a non-transitory machine-readable storage medium, including instructions configured to cause a data processing apparatus to: receive data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values; identify a common level node and a target level node for each of the hierarchies; identify a linking constraint, wherein the linking constraint includes a rule to adjust a node from a hierarchy to make it consistent with a node from another hierarchy; apply the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values; apply the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values; and generate a resolved hierarchy using the updated target node values.
 2. The computer-program product of claim 1, wherein the updated common node values have the same value as a value of one of the common level nodes before the linking constraint is applied to the common level node of each of the hierarchies.
 3. The computer-program product of claim 1, further comprising instructions configured to cause the data processing apparatus to: compute a change in target node value associated with each of the two or more hierarchies; determine that the change in target node value associated with one or more of the hierarchies are above a predetermined threshold; and re-apply the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating alternative common node values associated with the common level nodes, wherein the alternative common node values are the same node values, and wherein the alternative common node values are different than the updated target node values.
 4. The computer-program product of claim 1, wherein a target level node of a hierarchy includes a most accurate data of all nodes within the hierarchy.
 5. The computer-program product of claim 1, wherein applying a linking constraint to common level nodes forces common level node values associated with the common level nodes to be the same value.
 6. The computer-program product of claim 1, further comprising instructions configured to cause the data processing apparatus to: compute disaggregation factors for each of the nodes of two or more hierarchies; and determine, using the disaggregation factors for a parent node in a hierarchy, whether a set of child nodes of the parent node comply with flow conservation properties, wherein determining whether a set of child nodes of the parent node comply with flow conservation properties includes determining if a sum of the node values of the child nodes equals the node value of the parent node.
 7. The computer-program product of claim 5, wherein determining that the sum of the node values of the child nodes does not equal the node value of the parent node includes comparing the difference between the sum of the node values of the child nodes and the node value of the parent node to a predetermined threshold.
 8. The computer-program product of claim 6, further comprising instructions configured to cause the data processing apparatus to: determine that the set of child nodes of the parent node comply with flow conservation properties if the difference between the sum of the node values of the child nodes and the node value of the parent node are less than the predetermined threshold.
 9. A computing device, comprising: one or more processors; and a memory having instructions stored thereon, which when executed by the one or more processors, cause the computing device to perform operations including: receiving data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values; identifying a common level node and a target level node for each of the hierarchies; identifying a linking constraint, wherein the linking constraint includes a rule to adjust a node from a hierarchy to make it consistent with a node from another hierarchy; applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values; applying the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values; and generating a resolved hierarchy using the updated target node values.
 10. The computing device of claim 9, wherein the updated common node values have the same value as a value of one of the common level nodes before the linking constraint is applied to the common level node of each of the hierarchies.
 11. The computing device of claim 9, further comprising instructions, which when executed by the one or more processors, cause the computing device to perform operations including: computing a change in target node value associated with each of the two or more hierarchies; determining that the change in target node value associated with one or more of the hierarchies are above a predetermined threshold; and re-applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating alternative common node values associated with the common level nodes, wherein the alternative common node values are the same node values, and wherein the alternative common node values are different than the updated target node values.
 12. The computing device of claim 9, wherein a target level node of a hierarchy includes a most accurate data of all nodes within the hierarchy.
 13. The computing device of claim 9, wherein applying a linking constraint to common level nodes forces common level node values associated with the common level nodes to be the same value.
 14. The computing device of claim 9, further comprising instructions, which when executed by the one or more processors, cause the computing device to perform operations including: computing disaggregation factors for each of the nodes of two or more hierarchies; and determining, using the disaggregation factors for a parent node in a hierarchy, whether a set of child nodes of the parent node comply with flow conservation properties, wherein determining whether a set of child nodes of the parent node comply with flow conservation properties includes determining if a sum of the node values of the child nodes equals the node value of the parent node.
 15. The computing device of claim 14, wherein determining that the sum of the node values of the child nodes does not equal the node value of the parent node includes comparing the difference between the sum of the node values of the child nodes and the node value of the parent node to a predetermined threshold.
 16. The computing device of claim 15, further comprising instructions, which when executed by the one or more processors, cause the computing device to perform operations including: determining that the set of child nodes of the parent node comply with flow conservation properties if the difference between the sum of the node values of the child nodes and the node value of the parent node are less than the predetermined threshold.
 17. A computer implemented method, comprising: receiving data associated with nodes of two or more hierarchies, wherein nodes are associated with original node values; identifying a common level node and a target level node for each of the hierarchies; identifying a linking constraint, wherein the linking constraint includes a rule to adjust a node from a hierarchy to make it consistent with a node from another hierarchy; applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating updated common node values associated with the common level nodes, and wherein updated common node values are the same node values; applying the updated common node values to the target level node of each of the hierarchies, wherein applying the updated common node values includes generating updated target node values; and generating a resolved hierarchy using the updated target node values.
 18. The method of claim 17, wherein the updated common node values have the same value as a value of one of the common level nodes before the linking constraint is applied to the common level node of each of the hierarchies.
 19. The method of claim 17, further comprising: computing a change in target node value associated with each of the two or more hierarchies; determining that the change in target node value associated with one or more of the hierarchies are above a predetermined threshold; and re-applying the linking constraint to the common level node of each of the hierarchies, wherein applying the linking constraint includes generating alternative common node values associated with the common level nodes, wherein the alternative common node values are the same node values, and wherein the alternative common node values are different than the updated target node values.
 20. The method of claim 17, wherein a target level node of a hierarchy includes a most accurate data of all nodes within the hierarchy. 